@llhhbc Could you send your PR into master branch (v1.1 developing branch)?

@cosmo0920 I have rebase to master branch, and commit again.

@cosmo0920 Can it be merge?

@llhhbc Please ask @edsiper to review this PR.

@edsiper Can it be merge?

to be reviewed by @wfernandes @jasonkeene

@wfernandes @jasonkeene ^

@edsiper Apologies for the delay. We'll take a look at it soon.

I'm concerning about exporting function symbol naming rule.

On Output Golang proxy, we use CamelCase names for them.

How about using the following exporting function names?

• Golib_init -> GoLibInit
• Golib_filter -> GoLibFilter
• Golib_exit -> GoLibExit

I've added some nitpicks comments, but other implementation looks good to me.

It is fixed.

@cosmo0920 @wfernandes @jasonkeene Please check again.

Any timelines on when this will be complete? I'm about to start work on an log encryption filter in Lua but being able to write it in Go would be ideal.

Cheers!

I will update this filter now

@edsiper I have change code

@llhhbc Could you rebase off master? Current your branch is not able to build with the recent gcc compilers due to duplicated symbols.

@llhhbc Could you rebase off master? Current your branch is not able to build with the recent gcc compilers due to duplicated symbols.

OK

@cosmo0920 I have merge the master.

@wfernandes @jasonkeene @cosmo0920 @edsiper

@nokute78 please manage the review/cleanup/merge of this PR

How about passing raw message pack between Go and C ?
Fluent-bit-go supports messagepack decoder.
https://github.com/fluent/fluent-bit-go/blob/master/output/decoder.go
(By the way , we need an encoder to create filtered message pack data..)

Output plugin of C passes raw messagepack.

Currently, only string type is supported.
I think it is better to support number and other primitive data types.

How about passing raw message pack between Go and C ? Fluent-bit-go supports messagepack decoder. https://github.com/fluent/fluent-bit-go/blob/master/output/decoder.go (By the way , we need an encoder to create filtered message pack data..)

Output plugin of C passes raw messagepack.

fluent-bit/src/proxy/go/go.c

Line 121 in 0660382

int proxy_go_flush(struct flb_plugin_proxy_context *ctx,

Currently, only string type is supported. I think it is better to support number and other primitive data types.
@nokute78 I'll try it out.

@cosmo0920 What I need is not the output implemented with go, but the filter implemented with go. At present, fluentbit is fully supported in input and output, but the functions of filter and parse are insufficient, and it is very inconvenient to debug. The cgofilter I implemented has been online and has been running stably for 2 years, and it is also very convenient to extend it with go (because not most people can use c proficiently)

How about passing raw message pack between Go and C ? Fluent-bit-go supports messagepack decoder. https://github.com/fluent/fluent-bit-go/blob/master/output/decoder.go (By the way , we need an encoder to create filtered message pack data..)

Output plugin of C passes raw messagepack.

fluent-bit/src/proxy/go/go.c

Line 121 in 0660382

int proxy_go_flush(struct flb_plugin_proxy_context *ctx,

Currently, only string type is supported. I think it is better to support number and other primitive data types.

@nokute78 I'm not sure if this MR can be submitted. Because c and go, the parameters are currently passed through memory sharing, and after use, string is enough to use (because other types, the basic components of fluentbit can be solved), using msgpack has also been considered before, but it may be The cost is a bit big. i can try

@cosmo0920 What I need is not the output implemented with go, but the filter implemented with go. At present, fluentbit is fully supported in input and output,

Now, fluent-bit supports Wasm filter instead of Golang filter. Your pull requested feature collides our filter Wasm feature.
I'm not sure that your filter plugin written in Go can be migrated as Wasm filter.
Could you confirm your filter Golang can be replaced with our implemented Wasm filter feature? Thanks.

we will keep the Wasm as a preference for now. I appreciate the effort here, however I think its time to close it